home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970326-19970626 / 000259_news@newsmaster….columbia.edu _Sat May 31 14:55:18 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA04051
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 31 May 1997 14:55:17 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA14085
  7.     for kermit.misc@watsun; Sat, 31 May 1997 14:55:17 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc,comp.os.linux.misc
  11. Subject: Re: Transmit drops the last 10-14 characters
  12. Date: 31 May 1997 18:55:16 GMT
  13. Organization: Columbia University
  14. Lines: 67
  15. Message-ID: <5mps6k$do2$1@newsmaster.cc.columbia.edu>
  16. References: <338498B1.41C6@raleigh.ibm.com> <5m2brb$5l3$1@newsmaster.cc.columbia.edu> <338FC0D6.69AAE64D@mindspring.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:7109 comp.os.linux.misc:196675
  19.  
  20. In article <338FC0D6.69AAE64D@mindspring.com>,
  21. David Greeson  <dgreeson@mindspring.com> wrote:
  22.  
  23. (Discussing a problem using Linux C-Kermit to transmit bytes to a
  24. microprocessor, but the last few bytes are always lost...)
  25.  
  26. : ....
  27. : > : set file type binary (so it will transfer a byte at a time)
  28. : > : set flow xon
  29. : > :
  30. : > : Then I set the uP to receive the ascii file and type crtl-\c
  31. : > : C-kermit> transmit foo.bar
  32. : > :
  33. : > : The uP receives the whole file except for the last 10-14
  34. : > : characters.  The com port has a 16550A uart.
  35. :
  36. : The uP is using XON/XOFF for flow control and has a 16 byte
  37. : rcv/xmit fifos.  Using port diags on the uP, I do not see
  38. : the last 13 bytes of the file.  Also the port has not
  39. : been overrun'd.  I'm downloading s-records and each line
  40. : has a checksum which is verified.
  41. : ...
  42. : After the transmit finished, I typed  "c" to connect and I
  43. : could type one character and see that the uP port received
  44. : the character.  Also, if I set the uart type on the PC to
  45. : 16450 (setserial /dev/cua1 16450), only the last byte is
  46. : missing.
  47. :
  48. This reinforces my theory about a device driver bug; the last
  49. UART buffer's worth is not being flushed out when the device is 
  50. closed.
  51.  
  52. : I'm not sure what else to try or how to verify if its a kernel
  53. : problem.
  54. : 
  55. Get the Kermit source code:
  56.  
  57.   ftp://kermit.columbia.edu/kermit/archives/cku192.tar.gz
  58.  
  59. uncompress, untar.  Edit the file ckutio.c.  Find the ttres() routine
  60. (the one that restores the modes and settings of the tty device prior to
  61. closing it).  A few lines from the top of this routine:
  62.  
  63. #ifdef  NETCONN
  64.     if (netconn) return (0);            /* Network connection, do nothing */
  65. #endif  /* NETCONN */
  66.     sleep(1);                           /* <--- Add this line */
  67.  
  68. Save the file, then "make linux".  Try your application again.  Does it work?
  69. If so, this means means that tcsetattr() destroys any pending output, which
  70. I would call a bug.
  71.  
  72. If this change did not fix your application, then look for the ttclos()
  73. routine in the same source file (ckutio.c).  A few lines from the top of
  74. ttclos():
  75.  
  76.     if (ttfdflg)                        /* If we inherited ttyfd from */
  77.       return(0);                        /* another process, don't close it. */
  78.     sleep(1);                           /* <--- Add this line */
  79.  
  80. Save the file, "make linux" again, repeat the experiment.  If this change
  81. fixes the problem, it means that close() does not wait for output to drain,
  82. which I also would consider a bug.
  83.  
  84. Please let me know what you find.
  85.  
  86. - Frank